The Future of Programming

0:20 · 안녕하십니까. 이렇게 많은 컴퓨터 프로그래머 분들 앞에서 발표하게 되어 정말 기쁩니다. 여러분도 아시다시피, 컴퓨터는 우리 사회에서 점점 더 중요해지고 있습니다. 이제 전 세계적으로 문자 그대로 수천 대의 컴퓨터가 존재하며, 이 컴퓨터들은 모든 분야에서 사용되고 있습니다.
0:37 · 비즈니스와 회계에서부터 과학 실험에 이르기까지, 그리고 앞으로 또 어떤 분야에 사용될지는 아무도 모릅니다. 이처럼 컴퓨터는 점점 더 많아지고 있고, 가격은 낮아지고 있으며, 크기는 줄어들고 있습니다. 과거에는 컴퓨터가 이 홀 전체만 한 크기였지만, 이제는 정말 아주 작은 크기로 축소되었습니다. 지금은 컴퓨터 분야에서 정말 급격한 변화가 일어나는 시기입니다. 그래서 우리가 현재 알고 있는 것들을 바탕으로, 앞으로의 미래 프로그래밍을 조금 앞서 내다보는 것도 흥미로울 것이라 생각했습니다.
1:08 · 지금으로부터 약 40년 뒤의 프로그래밍은 어떤 모습일지 생각해 보는 것이죠. 오늘 제가 말씀드릴 내용은 지난 10년 정도 사이에 이루어진 정말 흥미로운 몇 가지 연구에 관한 것입니다. 저는 이것이 미래의 프로그래밍이 어떤 모습일지에 대한 시사점을 던져준다고 생각합니다. 최근 연구에서 나온, 제가 오늘 이야기하고 싶은 4가지 큰 아이디어, 즉 4가지 큰 주제가 있습니다. 하지만 이 4가지 큰 아이디어를 말씀드리기 전에, 먼저 아이디어를 수용한다는 것의 본질에 대해 이야기하고 싶습니다.
1:38 · 기본적으로 우리가 목격한 것은 기술은 빠르게 변하지만 사람의 생각은 천천히 변한다는 사실입니다. 즉, 새로운 기술을 받아들이는 것은 더 쉽지만, 새로운 사고방식을 받아들이는 것은 어려울 수 있습니다. 기술적인 측면에서 보면, 고든 무어(Gordon Moore)라는 분이 '인텔'이라는 회사를 가지고 계신데, 그분이 약 10년 전에 관찰한 바가 있습니다.
2:04 · 컴퓨터의 연산 능력이 시간이 지남에 따라 기하급수적으로 증가하고 있다는 것이었죠. 이를 지금 시점까지 유추해 보았는데, 그의 예측은 정확히 맞아떨어졌습니다. 그리고 이것이 얼마나 오래 지속될지는 아무도 모르지만, 꽤 타당해 보입니다. 여기서 얻을 수 있는 교훈은, 우리가 이것을 어느 정도 당연하게 여길 수 있다는 점입니다. 왜냐하면 그냥 기다리기만 하면 컴퓨터는 더 빨라지고 성능도 더 좋아질 것이고, 그 일은 그냥 일어날 것이기 때문입니다. 하지만 우리가 기다린다고 해서 그냥 일어나지 않는 일이 있습니다.
2:28 · 그것은 바로 사람들이 변화하고, 새로운 아이디어를 수용하는 것입니다. 예시를 들자면, 여러분 모두 이 장치를 기억하실 겁니다. 오래된 IBM 650이죠. IBM 최초의 범용 대량 생산 컴퓨터로, 우리 중 많은 사람이 이 장치로 프로그래밍을 처음 배웠습니다. 처음에 우리는 모두 절대 이진수(Absolute Binary)로 프로그래밍을 했습니다. 코딩을 할 때 말 그대로 숫자로 된 코드를 적었습니다.
2:54 · 각 명령어마다 숫자를 적었고, 그것이 우리가 했던 일, 즉 프로그래밍이었습니다. 그러고 나서 몇 년 후에 스탠 폴리(Stan Poley)가 나타나 '어셈블러(Assembler)'라고 부르는 것을 발명했습니다. 그것은 '상징적 최적화 어셈블리 프로그램(SOAP)'이라는 언어였습니다. 컴퓨터가 무언가를 더하기를 원하면 'ADD'라는 단어를 쓸 수 있었고, 메모리 주소를 하드코딩하는 대신 상징적인 변수 이름을 사용할 수 있었습니다. 프로그래밍에 대한 훨씬 더 강력한 사고방식이었죠.
3:25 · 생산성은 훨씬 더 높아졌고 실수는 훨씬 줄어들었습니다. 이 어셈블리를 이진수로 코딩하던 사람들에게 보여주었더니, 그들은 전혀 관심을 보이지 않았습니다. 그냥 이해하지 못했고, 이런 일을 하는 것에 대한 가치를 전혀 보지 못했습니다. 이처럼 이미 배운 것을 잊어버리고(unlearn) 새로운 방식으로 생각해야 하는
3:44 · 새로운 작업 방식에 대해서는 많은 저항이 따를 수 있습니다. 심지어 노골적인 적대감이 존재할 수도 있습니다. 우리가 사용하는 '폰 노이만 컴퓨터 구조'를 비롯해 수많은 것들을 발명한 위대한 과학자 존 폰 노이만(John von Neumann)은 "왜 기계어 외에 다른 것이 필요한지 모르겠다"라고 말한 적이 있습니다. 한 번은 그에게 여러 학생이 있었고, 학생들은 모두 이진수로 코딩을 하고 있었는데, 그의 학생 중 한 명이 시간을 좀 내어서
4:13 · 자신이 어셈블리로 글을 쓸 수 있도록 자신만의 작은 어셈블러를 작성했습니다. 그러자 폰 노이만은 그에게 불같이 화를 냈습니다. 어셈블리를 하느라 그 귀중한 기계 시간을 낭비했다는 것에 화가 난 것이었죠. 그런 사무적인 일은 사람이 직접 해야 하는 일이라고 생각했던 것입니다. 그리고 조금 후에 존 배커스(John Backus)와 그의 동료들이 '포트란(Fortran)'이라고 부르는 아이디어를 가지고 나왔을 때도 똑같은 이야기가 반복되었습니다.
4:35 · 이것은 이른바 상위 수준 언어(High-level language)로, 수학적 표기법을 쓰는 것처럼 공식을 작성할 수 있었고 루프(반복문)를 작성할 수도 있었습니다. 이것을 어셈블리 프로그래머들에게 보여주었더니, 이번에도 그들은 관심이 없었습니다. 그 안에서 어떠한 가치도 보지 못했고 이해하지 못했습니다. 그래서 제가 오늘 말씀드릴 4가지 큰 아이디어에 대해 이야기할 때, 이 점을 염두에 두셨으면 좋겠습니다.
4:58 · 무어의 법칙 덕분에 기술은 항상 발전하고 컴퓨터는 항상 더 유능해진다고 생각하기 쉽지만, 사람들이 배운 것을 잊고 새로운 방식으로 생각해야 하는 아이디어에는 종종 엄청난 양의 저항이 따릅니다. 이쪽 사람들은 자신들이 무엇을 하고 있는지 알고 있다고 생각하며, 자신들이 생각하는 방식만이 프로그래밍이고 다른 것은 프로그래밍이 아니라고 생각합니다. 따라서 새로운 아이디어를 수용하는 데는 많은 저항이 따를 것입니다.
5:26 · 오늘 제가 말씀드리고 싶은 4가지 아이디어는 모두 아주 최근의 연구에서 나온 것입니다. 첫 번째는, 오늘날 우리는 프로그램을 '코드'로 작성합니다. 컴퓨터가 수행할 기본적인 명령어 목록을 작성하죠. 그런데 데이터 구조를 직접 조작하면 컴퓨터가 따를 프로그램이 암묵적으로 구축되는 '데이터 직접 조작(Direct manipulation of data)'에 대한 정말 흥미로운 연구가 있었습니다. 두 번째로, 오늘날 우리는 프로시저(절차)를 작성합니다. 기본적으로 컴퓨터가 수행할 절차를 알려주죠. 이와 달리 '목표를 이용한 프로그래밍(Programming using goals)'에 대한 흥미로운 연구가 진행 중입니다.
5:58 · 컴퓨터에게 어떻게(How) 하는지가 아니라 무엇을 원하는지(What)를 말해주면, 컴퓨터가 스스로 방법을 알아내는 것입니다. 세 번째로, 오늘날 우리는 텍스트 파일 안의 텍스트 줄, 즉 목록을 사용하여 프로그래밍합니다. 그런데 지난 5년이나 10년 사이에 사람들이 정말 놀라운 일을 하고 있습니다. 컴퓨터에 비디오 디스플레이(모니터)를 연결하고 있는 것입니다. 그렇게 하면 모든 것이 바뀝니다. 정보의 공간적 표현에 대해 생각하기 시작하게 되죠. 그리고 네 번째는
6:23 · 우리가 순차적 프로그래밍 모델(Sequential programming model)로 프로그래밍을 한다는 점입니다. 기본적으로 컴퓨터가 명령어들을 하나씩 차례대로 수행하는 방식입니다. 하지만 하드웨어가 곧 바뀔 것입니다. 머지않아 대규모 병렬 하드웨어(Massively parallel hardware)를 보게 될 것이고, 그 하드웨어에서 프로그래밍을 하려면 견고한 병렬 프로그램 모델이 필요할 것입니다. 그럼 첫 번째 주제인 '데이터 직접 조작'에 대해 이야기해 보겠습니다. 이와 관련해
6:49 · 이반 서덜랜드(Ivan Sutherland)가 약 10년 전에 박사 학위 논문으로 진행했던 프로젝트를 보여드리겠습니다. '스케치패드(Sketchpad)'라는 시스템인데, 비디오 디스플레이 위에 그림을 그릴 수 있게 해주는 시스템이었습니다. 그는 라이트 펜(Light pen)을 들고 화면에 가져가서 선을 그리고, 또 선을 그리고, 이 윗부분을 그렸습니다. 지금 리벳(Rivet)을 그리려고 하는 중인데, 아주 엉성하게 그리고 있습니다. 옆으로 약간 기울어져 있고 모양도 일그러져 있죠.
7:16 · 그러더니 그는 스위치를 누른 채 컴퓨터 시스템에 이 선들 중 몇 개를 지정하여, 이 선들이 서로 수직이 되기를 원한다고 표시합니다. 그러자 시스템이 반복적 해결사(Iterative solver)를 실행하여 선들을 이리저리 돌려가며, 어떻게 하면 선들을 서로 수직으로 만들 수 있을지, 어떻게 직사각형으로 만들 수 있을지 알아냅니다.
7:41 · 기본적으로 시스템은 직사각형이 무엇인지 전혀 모릅니다. 사용자가 일련의 제약 조건(Constraints)을 직접 적용함으로써 직사각형을 그리게 만들 수 있었던 것이죠. 그리고 이것이 그냥 그림이 아니라 '프로그램'이 되는 이유는 이러한 제약 조건들이 동적으로 유지되기 때문입니다. 그가 그린 리벳이 있고, 모서리의 크기를 조절하거나 다른 부분의 크기를 조절하면
8:04 · 해결사(Solver)가 다시 작동하여 완벽한 직사각형으로 되돌려 놓습니다. 본질적으로 그는 직사각형을 그리는 프로그램을 만든 것이지만, 코드를 작성해서 만든 것이 아니라 데이터를 직접 조작하고 데이터에 일련의 제약 조건을 직접 적용하여 만든 것입니다. 이것은 간단한 예시이고, 그는 더 정교한 작업들도 해냈습니다. 여기 교량 시뮬레이션(Bridge simulation)이 있습니다.
8:28 · 실제로 다리의 물리학을 시뮬레이션하는 것인데, 그는 이것을 손으로 직접 그렸습니다. 여기 있는 숫자들은 다리의 특정 경간에 걸리는 장력(Tension)을 나타냅니다. 다리에 매달려 있는 하중(무게)을 변화시키면 다리가 변형되는데, 이 스케치패드 시스템은 다리에 대해 전혀 알지 못합니다.
8:48 · 그는 직접 그림을 그리고 매우 일반적인 일련의 제약 조건들을 직접 적용함으로써 이 교량 시뮬레이션 프로그램을 만든 것입니다. 저는 이것이 30~40년 후에 정말 중요해질 기술이라고 확실히 생각합니다. 미래에는 데이터 구조를 직접 조작하여 프로그래밍하고, 그것이 코드를 구축하도록 만드는 모습을 상상할 수 있습니다. 특히 이처럼 시각적이거나 물리적인 것들에 대해서 말이죠. 예를 들어 몇 십 년 후에 우리가 일종의 컴퓨터 네트워크(웹)상에서 어떤 문서 형식을 갖게 된다면
9:18 · 제 생각엔 우리 모두 마크업 언어나 스타일시트 언어 없이 직접 조작을 통해 그 모든 문서들을 만들고 있을 것이라 확신합니다. 그렇죠? 마크업 언어 같은 건 전혀 말이 안 될 것입니다. 이반 서덜랜드가 이미 지난 1962년에 그 방법을 우리에게 보여주었으니까요. 미래에는 모두 직접 조작 방식이 될 것이고, 정말 환상적일 것입니다.
9:41 · 두 번째로 이야기하고 싶은 것은 '목표를 이용한 프로그래밍'입니다. 우리는 스케치패드의 제약 조건 시스템에서 이것을 약간 보았습니다. 이반 서덜랜드는 직사각형을 그리고 싶었을 때, 직사각형의 각 변을 그리라는 절차를 작성하지 않았습니다. 대신 일련의 제약 조건을 적용했고, 시스템 스스로가 그 방법을 알아낸 것입니다.
10:06 · 어떻게 그 직사각형을 그려야 하는지 말이죠. 그러니까 그는 자신이 원하는 것("선들이 서로 수직이 되었으면 좋겠다")을 말했을 뿐, 어떻게(How) 해야 하는지는 말하지 않았고, 해결사(Solver)가 그 방법을 알아낸 것입니다. 이와 똑같은 또 다른 훌륭한 예시가 불과 몇 년 전에 나왔습니다. 칼 휴잇(Carl Hewitt)이 '플래너(Planner)'라고 부르는 시스템을 개발하고 있는데요.
10:21 · 정말 대단한 시스템입니다. 실제로 양방향으로 작동하죠. 절차적으로 순방향 추론을 할 수도 있고, 목표로부터 역방향 추론을 할 수도 있습니다. 만약 플래너에게 사과는 빨갛다고 알려주면, 사과를 보았을 때 '아, 이건 빨갛구나'라고 알게 됩니다. 하지만 반대로 "나는 빨간 무언가를 원해"라고 말하면, 시스템이 "그럼 사과를 한번 시도해 보자"라고 말할 수도 있죠. 즉, 여러분이 프로그램에서 원하는 '목표'와 '결과'를 바탕으로 프로그램을 표현할 수 있는 것입니다.
10:42 · 하지만 동시에 특정 유형의 하위 목표를 달성하기 위한 절차적 전략을 제공할 수도 있습니다. 프로그래밍을 생각하는 정말, 정말 흥미로운 방식이죠. 그리고 이 시스템은 몇 년 후 '프롤로그(Prolog)'라는 또 다른 시스템으로 이어지게 됩니다.
10:58 · 프롤로그는 플래너의 역방향 추론 부분만 유지한 시스템입니다. 즉, 프롤로그에서는 프로그램을 목표(Goals)로 표현하고, 시스템 자체가 탐색 등을 사용하여 그 목표를 달성하는 방법을 알아내려고 노력합니다. 이는 '논리 프로그래밍(Logic programming)'이라고 불리는 프로그래밍 장르로 이어지게 되지만, 여기서 진짜 중요한 부분은 그 이름이 아닙니다. 중요한 것은 프로그램을 '어떻게 실행할지에 대한 명령어 목록'이 아니라 '내가 무엇을 원하는지'로 표현하고, 컴퓨터 스스로 그 방법을 알아내게 한다는 점입니다. 이와 유사한 개념의 또 다른 예시가 바로 '패턴 매칭(Pattern matching)'입니다.
11:29 · 여러분 모두 '스노볼(Snobol)'을 기억하실 겁니다. 텍스트 조작 언어죠. 많은 텍스트가 있을 때 그것을 스노볼 스크립트나 프로그램에 통과시키고 싶어 하는데, 스노볼에는 패턴 매칭 기능이 내장되어 있었습니다. 그래서 텍스트와 대조하고 싶은 특정 패턴을 표현할 수 있었죠. 조금 후에 켄 톰슨(Ken Thompson)이 벨 연구소(Bell Labs)에서 '유닉스(Unix)'라고 부르는 시스템을 작업하고 있었는데... 예, 다들 아시는 그 유닉스 맞습니다.
11:53 · 아무튼 그는 텍스트에서 패턴 매칭을 수행하기 위해 정규 표현식(Regular expressions)의 개념을 채택했습니다. 패턴 매칭이 있으면, 방대한 텍스트를 소화하고 싶을 때 그 안을 절차적으로 훑고 지나가는 파서(Parser)를 일일이 작성할 필요가 없습니다. 그냥 "내가 찾고 있는 것은 대략 이런 형태다"라는 일종의 템플릿인 '패턴'을 제공하기만 하면 되죠.
12:15 · 그러면 시스템 자체가 그 패턴에 맞게 텍스트를 매칭하는 방법을 알아냅니다. 스케치패드의 제약 조건, 플래너, 프롤로그, 패턴 매칭 등의 이 모든 예시는 결국 컴퓨터에 상위 수준의 목표를 제시하며 "내가 찾는 건 이런 거야"라고 말하고, 컴퓨터 스스로 방법을 알아내게 만드는 예시들입니다. 그리고 우리는 최적화 컴파일러에서 이런 모습을 조금씩 보고 있지만, 저는 이것이 수십 년 후에 정말 널리 퍼질 것이라고 생각합니다. 그리고 이 목표 지향적인 접근 방식이
12:47 · 이토록 중요해지는 이유는 요즘 릭라이더(Licklider)가 퍼뜨리고 있는 이 아이디어와 관련이 있습니다. 여러분도 알다시피 릭라이더는 정부 기금 지원 기관인 ARPA를 이끌고 있으며, 전 세계의 모든 컴퓨터를 서로 연결하는 '글로벌 컴퓨터 네트워크'라는 아이디어를 밀어붙이고 있습니다. 그는 이것을 '은하간 컴퓨터 네트워크(Intergalactic computer network)'라고 부릅니다.
13:14 · 왜냐하면 엔지니어들은 항상 요구사항의 최솟값만 맞춰서 구현한다는 것을 그가 잘 알고 있기 때문입니다. 그래서 은하계를 아우르는 네트워크를 요구해야, 최소한 지구 전체를 아우르는 네트워크라도 얻을 수 있을 거라 희망하는 것이죠. 사람들은 이를 현재 '아파넷(ARPANET)'이라고 부르고 있고, 이제는 일종의 '인터넷(Inter-net)' 같은 것으로 변모하고 있습니다. 꽤 귀여운 아이디어고 잘 작동할지도 모르겠습니다. 그리고 이러한 글로벌 컴퓨터 네트워크를 갖게 되면, 릭라이더가 말하는 이른바 '외계인과의 통신 문제(Communicating with aliens problem)'에 직면하게 됩니다. 그는 이를 이렇게 표현했습니다. "본질적으로 이 문제는 공상과학 소설가들이 논하는 문제와 같다."
13:46 · "서로 완전히 무관한 지적 존재들 사이에 어떻게 통신을 시작할 것인가?" 그가 말하는 의미를 설명해 드리겠습니다. 예를 들어 어떤 컴퓨터 네트워크가 있고, 여기에 언제, 누가, 어떤 언어로 작성했는지 모르는, 특정 프로토콜을 사용하는 프로그램이 하나 있다고 해봅시다. 그리고 저기에는 또 다른 시기에 다른 누군가가 완전히 다른 언어로 작성한, 전혀 다른 언어를 구사하는 프로그램이 있습니다. 이 두 프로그램은 서로에 대해 전혀 모릅니다. 하지만 어느 시점에
14:18 · 이 프로그램은 자신이 원하는 서비스를 저 프로그램이 제공한다는 것을 알아차리고, 둘이 서로 이야기를 나누어야 하는 상황이 발생합니다. 서로에 대해 아무것도 모르고 완전히 다른 시대에 만들어진 이 두 프로그램이 이제 소통을 해야 하는 것이죠. 그럼 이들은 어떻게 소통을 하게 될까요?
14:34 · 실제로 작동할 수 있는, 규모 확장이 가능한 유일한 진짜 답은 '그들 스스로 서로 대화하는 방법을 알아내야 한다'는 것입니다. 즉, 서로 협상(Negotiate)을 해야 합니다. 서로를 탐색하고(Probe), 동적으로 공통의 언어를 찾아내어 정보를 교환하고 인간 프로그래머가 부여한 목표를 달성해야 합니다. 이것이 바로 우리가 이러한 인터넷을 갖게 되었을 때 이 목표 지향적인 메커니즘이
14:58 · 그토록 중요해지는 이유입니다. 왜냐하면 우리가 직접 절차를 작성할 수 없기 때문입니다. 우리는 원격에 있는 저 프로그램들과 통신하기 위한 절차를 미리 알 수 없습니다. 프로그램들 스스로가 서로 대화하기 위한 기능을 찾아내고 더 높은 수준의 목표를 달성해야 합니다. 전 세계적인 네트워크를 갖추게 된다면, 저는 이것만이 확장 가능한 유일한 모델이라고 생각합니다. 작동하지 않을 방식,
15:21 · 그러니까 완전히 재앙이 될 방식은—제가 여기서 용어를 하나 만들어 보겠는데—바로 'API'라는 개념입니다. 인간 프로그래머가 원격 프로그램이 노출한 고정된 인터페이스에 맞춰 코드를 작성한다는 개념이죠. 우선, 이것은 프로그램들이 이미 서로에 대해 알고 있을 것을 요구합니다. 그리고 이 프로그램의 언어로 코드를 작성하는 순간 두 프로그램은 서로 묶이게 됩니다. 그러면 첫 번째 프로그램은 밖으로 나가서 동일한 서비스를 구현하는 다른 프로그램을 찾아 나설 수 없게 됩니다. 서로 종속되어 버리기 때문이죠. 만약 이 프로그램의 언어가 바뀌면
15:53 · 상대 프로그램도 망가집니다. 정말 취약하고 확장성이 없습니다. 그리고 무엇보다 최악인 점은, 본질적으로 기계어 문제와 똑같다는 것입니다. 기계가 알아서 처리해야 할 하위 수준의 세부 사항을 인간이 직접 다루고 있는 꼴이죠. 그래서 저는 미래에 이런 일은 절대 일어나지 않을 것이라고 확신합니다. 미래에 우리에게 API 같은 것은 없을 것입니다. 대신 서로 대화하는 방법을 스스로 알아낼 수 있는 프로그램들이 존재할 것이며, 그러기 위해서는 '목표 프로그래밍'이 필요할 것입니다.
16:29 · 제가 말씀드리고 싶은 세 번째 큰 아이디어는 '정보의 공간적 표현(Spatial representation of information)'입니다. 오늘날 우리의 프로그램은 기본적으로 수많은 텍스트 줄, 즉 텍스트 줄로 가득 찬 커다란 파일입니다. 프로그램이 천공 카드 묶음이나 종이 테이프, 혹은 자기 테이프에 담겨 있을 때는 그것이 자연스러웠습니다. 이러한 매우 선형적인 매체에서는 프로그램이 선형적인 형태를 갖는 것이 당연하니까요.
16:53 · 텔레타이프(원격 타자기)를 사용한다면, 텔레타이프는 텍스트 줄을 뱉어내기 위해 만들어진 장치이므로 당연히 프로그램도 텍스트 줄 형태로 작성될 것입니다. 하지만 앞서 언급했듯이, 지금 사람들이 정말 기발하고 파격적인 일을 하고 있습니다. 컴퓨터에 비디오 디스플레이를 연결하고 있는 것이죠. 컴퓨터에 비디오 디스플레이가 연결되면, 컴퓨터를 정보를 공간적으로 표현할 수 있는 아주 역동적인 종이 한 장처럼 생각하기 시작할 수 있습니다.
17:21 · SRI의 더그 엥겔바트(Doug Engelbart)는 '온라인 시스템', 즉 'NLS'라고 부르는 시스템을 가지고 있습니다. 그가 5년 전에 대대적인 시연을 했는데 여러분도 보셨을지 모르겠습니다. 이 시스템에는 정말 놀라운 점이 많은데, 가장 놀라운 것 중 하나는 비디오 화면에 정보를 표시한다는 개념입니다. 그는 '마우스(Mouse)'라고 불리는 장치를 가지고 있는데, 테이블 위에서 이리저리 굴리는 장치입니다. 말로 설명하긴 어렵지만,
17:49 · 이것을 사용해 화면의 다른 부분을 가리키고(Point), 가리킨 부분에 대해 더 많은 정보를 원한다는 표시를 할 수 있습니다. 또한 정보의 '다양한 뷰(Views)'라는 개념도 가지고 있습니다. 여기 보시는 것처럼 목록(List) 형태로 되어 있는 데이터가 있을 때, 이를 뒤집어서 동일한 데이터를 2차원 다이어그램 형태로 볼 수도 있습니다.
18:11 · 이처럼 동적인 정보를 어떻게 공간적으로 표현할 수 있을지 본격적으로 고민하기 시작한 것입니다. 비슷한 시기에 랜드 연구소(RAND Corporation)에서 나온 '그레일(GRAIL)'이라는 훌륭한 시스템도 있습니다. 이것은 비디오 디스플레이 상에서 플로우차트(순서도)를 사용하여 프로그래밍을 하는 시스템입니다. 여기서 입력 장치는 태블릿 위의 스타일러스 펜이며, 이것으로 플로우차트를 직접 그릴 수 있습니다. 어떻게 작동하는지 보여드리겠습니다.
18:42 · 프로그래머가 완전히 자유롭게 손으로 상자(Box)를 그리고 있습니다. 상자를 그리면 시스템이 그것이 상자임을 인식하고 플로우차트 상자로 변환합니다. 그가 하는 그림 그리기에 의미론적 정보(Semantic meaning)를 부여하는 것이죠. 여기에 라벨을 붙이고 싶으면 그냥 글자를 쓰기 시작하면 됩니다. 시스템이 그의 손글씨를 인식합니다. 1968년도 시스템이 손글씨를 인식해서 텍스트로 바꾸는 것이죠. 여기서 이
19:12 · 상자와 저 상자를 선으로 연결하는 등의 작업을 합니다. 이 모든 것이 매우 직접적인 조작입니다. 만약 이 선을 지우고 싶다면 그냥 선 위를 휘갈겨 지우면 선이 사라집니다. 비디오 디스플레이가 있고 2차원으로 무언가를 표현할 수 있을 때, 프로그래밍이 무엇을 의미하는지 진정으로 고민한 결과물입니다. 하지만 제가 정보의 공간적 표현을 말할 때, 단지 플로우차트 같은 것만 이야기하는 것은 아닙니다. 제록스(Xerox)는
19:37 · 팔로알토에 작은 연구소를 가지고 있는데, 그곳의 몇몇 젊은 친구들이 '스몰토크(Smalltalk)'라고 부르는 것을 연구하고 있습니다. 스몰토크에서 소스 코드는 텍스트로 표현되지만, 코드가 뭉텅이로 들어있는 길고 커다란 텍스트 파일 같은 것은 존재하지 않습니다. 코드가 공간적인 방식으로 조직되어 있죠. 여기 그들이 '브라우저(Browser)'라고 부르는 화면이 있습니다.
19:56 · 이 목록을 보면, 여기에는 클래스(Classes)들의 전체 컬렉션이 있고, 여기에는 해당 컬렉션에 속한 모든 클래스가 있으며, 여기에는 그 클래스의 모든 프로토콜이 있고, 여기에는 그 프로토콜의 모든 메서드(Method)가 있습니다. 그리고 여기 해당 메서드의 소스 코드가 보입니다. 즉, 메서드 정의 자체는 텍스트이지만, 하나의 거대한 텍스트 줄이 아니라 공간적으로 조직되어 있어서 시스템을 매우 빠르게 돌아다니며 무슨 일이 일어나고 있는지 파악할 수 있습니다. 이처럼 엥겔바트의 NLS, 그레일, 스몰토크 사이에는 정보를 공간적으로 표현하는 매우 다양한 방법들이 존재합니다.
20:29 · 저는 40년 후에는 우리가 더 이상 텍스트 파일로 코드를 작성하지 않을 것이라고 전적으로 확신합니다. 우리는 이미 나아갈 길을 보았습니다. 덧붙여 말씀드리자면, 제가 방금 보여드린 모든 시스템과 엥겔바트의 NLS 시스템, 그레일, 스몰토크, 그리고 일리노이 대학교에서 진행 중인 '플라토(Plato)'라는 정말 흥미로운 시스템 등은 인터랙티브 컴퓨팅(Interactive computing)이라는 새로운 흐름의 일부입니다. 컴퓨터 앞에 앉아서
21:00 · 실제로 실시간으로 컴퓨터와 상호작용하는 방식이죠. 이 연구자들은 자신들이 새로운 개념을 증명하려 한다는 것을 잘 알고 있었기 때문에, 시스템을 최하단부터 사용자 인터페이스가 항상 즉각적으로 반응하도록 설계했습니다. 무엇과 상호작용하든 즉시 반응을 얻을 수 있죠. 마치 물리적인 물체를 시뮬레이션하는 것과 같습니다. 따라서 인터랙티브 컴퓨팅이 본격적으로 궤도에 오르면—
21:25 · 그리고 저는 그렇게 될 것이라 생각합니다만—40년 뒤의 우리 사용자 인터페이스(UI)는 사용자가 상호작용할 때 그 어떤 종류의 지연(Delay)이나 렉(Lag)도 겪지 않을 것이라는 점이 꽤 자명하다고 봅니다. 왜냐하면 이들이 이미 60년대에 즉각적으로 반응하는 UI를 갖추는 것이 얼마나 중요한지 증명해 보였기 때문입니다. 우리의 컴퓨터가 수백만 배 더 빨라질 텐데, 운영체제나 사용자 인터페이스에 지연이나 렉이 존재할 이유는 당연히 없겠죠. 정말 흥미진진한 일일 것입니다.
21:57 · 네 번째로 말씀드리고 싶은 것은 바로 '병렬 프로그래밍(Parallel programming)'입니다. 오늘날 우리의 프로그램은 기본적으로 명령어의 순서, 즉 컴퓨터에 이것을 하고, 그다음에 저것을 하고, 또 그다음을 하라는 식입니다. 우리가 이러한 순차적 모델(Sequential model)로 프로그래밍을 하는 이유 중 하나는
22:17 · 하위 하드웨어와 관련이 있습니다. 우리는 지금까지 '폰 노이만 컴퓨터 구조'라고 불리는 컴퓨터 아키텍처를 사용해 왔습니다. 프로세서가 하나 있고 그것이 커다란 메모리에 연결되어 메모리로부터 워드(데이터 단위)를 가져오는 구조죠. 따라서 순차적 프로그램 모델은
22:37 · 프로세서가 단 하나만 있을 때 자연스럽습니다. 프로세서는 한 번에 한 가지 일만 할 수 있으므로, 프로세서가 할 일의 목록을 주면 프로세서가 그중 하나씩을 처리해 나가는 것이죠. 하지만 폰 노이만 아키텍처의 한 가지 특징은 이 메모리의 대부분이 대부분의 시간 동안 유휴(Idle) 상태라는 점입니다. 여기 작은 프로세서가 있어서 나름대로 최대한 빨리 처리하고 있지만, 메모리에서는 단 하나의 워드만 접근될 뿐 나머지 메모리는 그냥 멍하니 기다리고 있습니다. 그리고 그것은 프로세서가
23:09 · 진공관이나 릴레이로 만들어져서 크고 비싸며, 메모리 역시 코어(자기코어)나 회전 드럼으로 만들어져서 크고 비싸던 시절에는 통하는 방식이었습니다. 그때는 그런 식으로 넘어갈 수 있었죠. 하지만 지금 컴퓨팅 분야에 모든 것을 바꿀 것이라 생각되는 엄청난 발명품이 등장하기 시작했습니다. 바로 '집적 회로(Integrated circuit)', 즉 반도체 집적 회로입니다.
23:35 · 이것은 '인텔'이라는 회사가 만든 것으로 '마이크로프로세서(Microprocessor)'라고 불리며, 단 하나의 실리콘 조각 위에 프로세서 전체를 올린 것입니다. 프로세서 전체가 오직 트랜지스터로만 이루어져 있죠. 트랜지스터는 실리콘에 에칭(식각)해서 새겨 넣은 작은 그림과 같고, 전체 회로는 실리콘에 새긴 하나의 크고 복잡한 그림과 같습니다. 우리의 프로세서가 실리콘 위의 트랜지스터로 만들어지듯, 우리의 메모리 역시 마찬가지로
24:04 · 실리콘 위의 트랜지스터로 만들어질 것입니다. 모두 같은 재료죠. 그런 관점에서 폰 노이만 아키텍처를 바라보면, 한쪽에는 처리를 위해 정말 열심히 일하는 트랜지스터들이 있는 반면, 다른 한쪽에는 거대한 트랜지스터 배열이 있지만 그 대부분은 그냥
24:19 · 가만히 앉아서 기다리고 있을 뿐입니다. 연산도 안 하고 아무것도 하지 않죠. 따라서 그 트랜지스터들이 일을 하게 만들고 싶다면, 즉 실리콘 조각 하나에서 얻을 수 있는 연산의 양을 실제로 극대화하고 싶다면, 좀 더 이런 형태에 가까운 것들을 바라보기 시작해야 합니다.
24:43 · 그렇죠. 실리콘 위에서 컴퓨터가 궁극적으로 지향해야 할 모습은 수많은 작은 컴퓨터들이 되는 것입니다. 자체 프로세서와 자체적인 작은 상태(State)를 가지고 각자 자기 일을 하면서 서로 통신하는 tiny 컴퓨터들의 거대한 배열 말이죠. 그것이 실리콘 면적당 연산량을 극대화하는 방법입니다.
25:00 · 게다가 이것은 확장(Scale)도 가능합니다. 트랜지스터가 더 작아지거나 실리콘 다이(Die)가 더 커져서 여유 공간이 생기면, 그냥 더 많은 프로세서로 채워 넣으면 됩니다. 정말 쉽죠. 이것이 바로 우리가 미래에 프로그래밍하게 될 아키텍처입니다. 인텔이 어떻게든 마이크로프로세서 시장을 독점해서 이 폰 노이만 아키텍처를 30년 동안 더 밀어붙이지 않는 한은 말이죠. 하지만 그런 일은 일어나지 않을 것입니다. 우리는 이러한 병렬 프로세서 위에서 프로그래밍을 하게 될 것입니다. 그리고 이런 하드웨어를 갖게 되면 "여기에 어떻게 프로그래밍을 해야 하지? 이런 하드웨어를 위한 프로그래밍 모델은 무엇인가?"를 고민해야 합니다. 오늘날 우리가 프로그래밍을 하는 방식은
25:40 · 바로 스레드(Threads)와 락(Locks)을 사용하는 방식입니다. 제어를 위한 몇 개의 순차적 스레드를 두고, 마이크로프로세서를 멀티플렉싱(시분할)하여 마치 병렬로 돌아가는 것처럼 꾸민 뒤, 공유 자원에 접근할 때 서로를 차단하기 위해 락을 걸죠. 하지만 이런 방식은 절대 통하지 않을 것입니다. 확장성이 없습니다. 수백 개의 스레드가 동시에 같은 공유 메모리를 두드려 대는 상황을 인간이 논리적으로 추론할 수는 없습니다. 스레드와 락은 막다른 골목(Dead end)입니다. 만약 40년 후에도 우리가 여전히 스레드와 락을 쓰고 있다면, 우리는
26:09 · 짐 싸서 집에 가야 합니다. 공학 분야로서 완전히 실패한 것이니까요. 스레드와 락이 아니라면 무엇이 작동할까요? 플래너(Planner)를 만들었던 바로 그 칼 휴잇(Carl Hewitt)이 '액터 모델(Actor model)'이라 부르는 아이디어를 내놓았습니다. 액터 모델은 물리학에서 영감을 받은 연산 모델입니다. 물리학에서는 수많은 입자가 존재하고,
26:32 · 그 모든 입자는 독립적으로 각자의 일을 합니다. 자신만의 작은 상태를 가지고 주변에 있는 다른 입자들과 상호작용하죠. 칼 휴잇은 컴퓨터 프로세스도 같은 방식으로 생각했습니다. 수많은 프로세스가 있고, 이들은 모두 비동기적으로 각자의 작은 일을 하며 자신만의 상태를 가지고 서로 메시지를 보냅니다. 프로그래밍을 생각하는 정말 흥미롭고 새로우며 신나는 방식입니다.
26:55 · 현재 이와 관련된 논의가 뜨겁게 달아오르고 있습니다. 프랑스의 질 칸(Gilles Kahn)도 어떤 아이디어를 가지고 있고, 토니 호어(Tony Hoare) 역시 '통신 순차 프로세스(CSP)'라고 부르게 될 개념을 가지고 이 분야에 뛰어들고 있으며, 로빈 밀너(Robin Milner)까지 이 파티에 동참할지도 모릅니다. 정말 흥미진진한 일들이 일어나고 있죠. 오늘 발표에서 이 특정 모델들의 세부 사항까지는 중요하지 않습니다. 다만 액터 모델이
27:21 · 스웨덴 전화회사(에릭슨) 같은 곳에서 채택된다면 꽤 멋지겠다는 생각은 듭니다. 조금 특이하긴 하겠지만요. 하지만 여기서 중요한 본질은 우리에게 대규모 병렬 하드웨어가 주어질 것이며, 그 하드웨어에 걸맞은 견고한 병렬 프로그래밍 모델이 필요하고, 우리가 미래에 사용하게 될 것은 바로 이와 유사한 형태일 것이라는 점입니다.
27:46 · 이것이 제가 오늘 이야기하고 싶었던 네 가지입니다. 첫째, 스케치패드처럼 그림을 그리고 동적으로 제약 조건을 추가하며, 프로그램에 명령어를 작성하는 대신 데이터 구조를 직접 조작하는 '데이터 직접 조작'. 둘째, 스케치패드의 제약 조건, 플래너, 프롤로그, 정규 표현식 같은 패턴 매칭처럼 컴퓨터에 무엇을 하고 싶은지 말하면 컴퓨터 자체의 해결사가 그 방법을 알아내는 '목표와 제약 조건을 이용한 프로그래밍'.
28:21 · 셋째, 비디오 디스플레이가 있기 때문에 더 이상 텍스트 파일은 쓰지 않고 정보를 공간적으로 표현하는 '정보의 공간적 표현'. 넷째, 스레드와 락이나 순차적 사고 방식에서 벗어나 병렬 하드웨어와 병렬 프로그램 모델을 바탕으로 하는 '근본적으로 병렬적인 사고 방식'. 이것이 제가 말씀드리고자 한 네 가지 주제였습니다.
28:44 · 아시다시피 제가 미래에 대해 몇 가지 예측을 하려고 노력했지만, 미래를 실제로 예측할 수는 없습니다. 이것들은 좋은 아이디어들이지만 앞으로 어떻게 될지는 모릅니다. 아이디어라는 것은 분리되기도 하고 합쳐지기도 하며, 유행을 탔다가 사라지기도 하니까요. 어떤 일이든 일어날 수 있습니다.
29:01 · 하지만 만약 40년 후에도 우리가 여전히 텍스트 파일 속의 프로시저로, 순차적 프로그래밍 모델 안에서 코딩을 하고 있다면 그것은 정말 부끄러운 일일 것이라 생각합니다. 그것은 우리가 컴퓨터 과학의 이 정말 풍요로웠던 시기로부터 아무것도 배우지 못했음을 시사할 것이고, 일종의 비극이 될 것입니다. 하지만
29:24 · 이러한 아이디어들이 쓰이지 않는 것보다 더 큰 비극은, 이 아이디어들이 완전히 '잊히는 것'입니다. 훗날 누군가에게 이 과거의 업적들을 보여주었을 때, 그들이 진심으로 놀라워하는 상황 말이죠. 하지만 그것조차도 가장 큰 비극은 아닙니다. 진짜 비극은 사람들이
29:43 · 애초에 '프로구래밍 모델에 대한 새로운 아이디어를 가질 수 있다'는 사실 자체를 잊어버리는 것입니다. 제가 생각하는 최악의 시나리오가 무엇인지 설명해 드리겠습니다. 그것은 바로 다음 세대의 프로머들이
29:59 · 이러한 아이디어들을 전혀 접하지 못한 채 자라나는 것입니다. 다음 세대, 또 그 다음 세대의 프로그래머들이 프로그래밍에 대해 단 한 가지 사고방식만 교육받으며 자라는 것이죠. 그래서 그들은 그 방식 안에서만 일하고, 세부 사항을 다듬고, 그 특정 프로그래밍 모델을 나름대로 완성한 뒤 그것을 다 알아냈다고 생각합니다. 그리고 그것을 그다음 세대에게 가르치죠. 그러면 그 두 번째 세대는 "아, 모든 건 이미 다 해결되었구나. 우리는 프로그래밍이 무엇인지 알고, 우리가 무엇을 하고 있는지 알고 있어"라고 생각하며 자라게 됩니다. 일종의 '독단(Dogma)' 속에서 자라나게 되는 것이죠.
30:31 · 일단 독단(Dogma) 속에서 자라나면, 거기서 벗어나기란 정말 어렵습니다. 60년대와 70년대 초반이라는 이 특정 시기에 왜 이 모든 아이디어들과 수많은 훌륭한 아이디어들이 쏟아져 나왔는지 그 이유를 아십니까? 왜 그 시절에 이 모든 일이 일어났을까요? 컴퓨터로 실제로 무언가를 할 수 있을 만큼 기술이 무르익은 시기였으면서도, 동시에 '프로그래밍이 무엇인지' 아는 사람이 아무도 없던 초기 시절이었기 때문입니다.
31:03 · 프로그래밍이 원래 어떠해야 하는지 아는 사람이 아무도 없었고, 본인들이 모른다는 사실을 스스로 잘 알고 있었습니다. 그래서 그들은 온갖 방법을 다 시도해 보았습니다. 그들의 생각은 온전히 자유로웠고, "이렇게 프로그래밍해 보면 어떨까? 저렇게 프로그래밍해 보면 어떨까?"라며 머릿속에 떠오르는 것은 무엇이든 그냥 시도해 보았던 것이죠.
31:22 · 그렇기에 창의적인 사람으로서 가질 수 있는 가장 위험한 생각은 '내가 지금 무엇을 하고 있는지 잘 알고 있다'고 믿는 것입니다. 자신이 무엇을 하고 있는지 안다고 생각하는 순간, 다른 방법을 찾는 것을 멈추게 되고 다른 방식을 바라보는 시야를 잃어버리기 때문입니다. 눈이 멀어버리는 것이죠. 마치 여기 이진수로 코딩하던 사람들처럼 말입니다.
31:46 · 누군가 그들에게 어셈블리 언어를 보여주고, 누군가 포트란을 보여주어도 그들은 그것을 보지조차 못합니다. 그들의 머리 위로 그냥 지나가 버리죠. 왜냐하면 자신들이 무엇을 하고 있는지 잘 안다고 생각하니까요. "내가 하는 것만이 프로그래밍이고 저건 프로그래밍이 아니야"라고 여기기 때문에, 이 훨씬 더 강력한 사고방식을 완전히 놓쳐버리는 것입니다. 그러므로 이 강연이 전하고자 하는 메시지는—사실 이 기술적인 내용 자체가 본질이 아닙니다—이 강연의 진짜 메시지는, 여러분이 이런 사람이 되고 싶지 않다면, 그리고 새로운 사고방식에 열려 있고 이를 기꺼이 받아들이며
32:18 · 나아가 새로운 사고방식을 발명하고 싶다면, 그 첫걸음은 스스로에게 이렇게 말하는 것입니다. "나는 내가 무엇을 하고 있는지 모른다. 우리 분야는 우리가 무엇을 하고 있는지 전혀 모른다." 우리는 프로그래밍이 무엇인지 모르고, 컴퓨팅이 무엇인지 모르며, 심지어 컴퓨터가 무엇인지조차 모른다고 말해야 합니다. 이 사실을 진정으로 이해하고 진심으로 믿을 때, 비로소 여러분은 자유로워지고 어떤 생각이든 할 수 있게 됩니다. 감사합니다.